Ratified in 2001, the International Telecommunication Union (ITU-T) recommendation G.7041 addresses the need for a generic method of mapping client signals for transmission over a transport network. In the interest of interoperability, the generic framing procedure (GFP) as defined by G.7041 allows client signals to be mapped into a framed payload suitable for Synchronous Digital Hierarchy (SDH) virtual containers (VCs) as well as Optical Transport Network (OTN) Optical Data Units (ODUs).
As illustrated in FIG. 1, the basic structure of a frame created under GFP consists of a four-byte core header and a payload area of up to 65535 bytes. Two bytes of the core header (1) are dedicated to a Payload Length Indicator (PLI) which indicates the size of the appended payload area. The other two bytes (2) comprise the Core Header Error Correction (cHEC) field, containing a 16-bit Cyclic Redundancy Check (CRC) code which enables single- and multi-bit error correction. The payload area consists of a payload header (3) which can vary in size from 4 to 64 bytes and carries two bytes of information indicating the type of payload contained within the payload area as well as a 16-bit CRC HEC to protect the type field, and an additional 0 to 62 bytes which can contain information specific to the technology of the transport network over which the frame is to be transmitted. The remainder of the payload area (4) is comprised of the payload information field itself, containing the client signal to be encoded and framed under GFP as well as an additional four-byte payload Frame Check Sequence (pFCS) that comprises a 32-bit CRC code to protect the integrity of the payload information area.
The GFP outlined above, however, is not sufficient to encompass the needs of all network applications; these applications are broadly divided into those which the recommendation defines as either Protocol Data Unit (PDU) oriented, or block-code oriented. PDU-oriented applications such as Internet Protocol (IP) or Point-to-Point Protocol (PPP) rely on the transport of discrete, individually-framed packets of information. For these applications, G.7041 recommends Frame-Mapped GFP (GFP-F), a subset of GFP wherein the client frame is adapted to that of the recommendation in a “frame-by-frame mapping of the client payload” into the GFP payload information area (G.709, page 29). Other block-coded applications, however, such as Gigabit Ethernet (GbE), deal in high-volume transport of data, and thus are susceptible to small amounts of latency in transmission; for these applications, the frame-by-frame mapping of client frames to GFP frames in GFP-F would create intolerable wait times in transmission as network elements worked on each individual client frame. For those applications which require a constant streaming of encoded data, a different type of GFP is required.
Transparent-mapped GFP (GFP-T) is designed to meet the needs of these low-latency applications. In GFP-T, the stream of 8-bit/10-bit (8 B/10 B) block-encoded characters utilised by such high-speed, low-latency applications as GbE is mapped into a fixed-size 64-bit/65-bit (64 B/65 B) payload information area, irrespective of the size of the client frame itself. The 8 B/10 B characters are decoded and then encoded in 64 B/65 B code. Each line of 64 B/65 B code contains eight bytes (64 bits) of decoded 8 B/10 B payload information as well as a single leading bit (flag bit) which indicates whether or not the included payload information contains any control codes. The payload information area of each GFP-T frame contains a plurality of “superblocks,” illustrated in FIG. 2, wherein each superblock consists of eight 64 B/65 B codes, and each code is further broken down into a set of eight one-byte “words.” Each superblock therefore consists of 64 bytes of payload data and a single octet of flag bits which are grouped together as a trailing byte. Following the trailing byte is a 16-bit CRC code to protect the integrity of the superblock. The number of superblocks contained in the GFP-T frame is dependent upon the “base, uncoded rate of the client signal and on the transport channel capacity” (G.709, page 45). The minimum size of a GFP-T frame contains a single superblock, and accommodates a client signal rate of 160 Mb/s; to fulfil the needs of GbE, wherein the transport network operates at a rate of one Gb/s, a minimum of 95 superblocks per frame are required. These high rates of transmission are indicative of the pressing need to reduce the latency in processing the GFP-T frames, on both transmit and receive sides of the network.
Compounding the issue of latency is the dependence of GFP upon 16- and 32-bit CRC codes to maintain the integrity of both headers and payload. When payload data is encoded, the binary information is run through a particular polynomial to produce a checksum, or CRC code, which represents the remainder of a quotient after the polynomial has been divided by a particular divisor; the CRC code is then appended to the payload information and transmitted with the frame. At the receive side, as the information is decoded, the binary information is run through the polynomial once more, and the results are checked against a syndrome table to ensure that the received value matches the expected value. If the received value does not match the expected value, it may indicate either a single- or multi-bit error. Thus it is necessary to process the CRC codes and compare the incoming data with the expected results. In particular, such an apparatus must specifically address the superblock, as every GFP-T frame consists of a plurality of said superblocks, each with its own 16-bit CRC code.
The prior art includes methods by which the superblocks of a GFP-T frame and the appended CRC codes may be processed. Specifically, the prior art illustrated in FIG. 3 addresses these needs by implementing an eight-by-eight byte buffer (5) to hold the 64 bytes of payload data in the superblock, a buffer to hold the octet of flag bits (6), and a three-stage method of error correction, which consists of three separate checks for the remainder of a CRC calculation performed by a CRC calculation circuit (7) against two separate syndrome tables, one for single bit errors (8) and one for multi-bit errors (9). While this method is sufficient for older transport networks, recent developments in technology have permitted higher speeds of transmission including 10 GbE, 40 GbE, and 100 GbE. These higher rates of transmission are more sensitive to the effects of latency, and thus the prior art is insufficient in addressing the needs of contemporary transport networks. Thus it is necessary to produce a means by which the superblocks of a GFP-T frame may be processed and undergo error correction while reducing latency.